A PoC System makes use of the infrastructure provided by SIP technology for session establishment, session management and session termination. While providing multiple sessions, it is understandable the number of simultaneous sessions cannot be indefinite considering the limited resources available.
In the PoC system, multiple sessions are managed in a PoC server or in a PoC client. These two cases will be described with reference to FIGS. 1 and 2.
With reference to FIG. 1, a description will first be made of a PoC simultaneous session scenario at a PoC server. FIG. 1 illustrates a scenario describing a server behavior when the number of simultaneous PoC sessions has exceeded the limit.
In FIG. 1, it is assumed that User A wants to invite User B for joining a PoC session, User B has involved in multiple PoC Sessions, he has reached the maximum limit that has been supported, and the PF of User B supports the simultaneous sessions. Hereinbelow, the terms PoC user and PoC client will be used interchangeably in the same sense.
Referring to FIG. 1, when User A wants to invite User B to join a PoC conversation, he sends an INVITE message addressing User B. A controlling PoC Function (hereinafter, referred to as CF) B routes the INVITE message to a participating function via an SIP signaling procedure in steps 100 to 104. PF B receives the INVITE message, and checks whether User B has reached his maximum limit for the simultaneous sessions in step 106. If User B has already reached the maximum limit of the simultaneous PoC sessions, PF B replies to the INVITE message with a ‘486 Busy’ message in steps 108 to 112. PF B keeps on replying with the busy state notification till User B has released at least one of the existing PoC sessions.
As described above, when User A invites User B to join a PoC session in the PoC simultaneous session scenario at the PoC server, Participating PoC Function (hereinafter, referred to as PF) B determines the availability of User B before routing the invitation request. If PF B recognizes that User B is “participating in the maximum number of simultaneous sessions”, it sends the 486 Busy message to CP B. Then CF B determines User B as busy and responds back to User A automatically.
With reference to FIG. 2, a PoC simultaneous session scenario at a PoC client will be described. FIG. 2 illustrates a scenario describing a client behavior when the number of simultaneous PoC sessions has exceeded the limit.
Referring to FIG. 2, it is assumed that User A wants to invite User B for joining a PoC session, User B has involved in multiple PoC Sessions, he has reached the maximum limit that has been supported, and the PF of User B supports the simultaneous sessions, as with FIG. 1.
When User A wants to invite User B to join a PoC conversation, he sends an INVITE message addressing User B. Controlling PoC Function (hereinafter, referred to as CF) B routes the INVITE message to the PF via an SIP signaling procedure in steps 200 to 204. PF B routes the INVITE message to User B in steps 206 and 208. PoC client B checks the allowed maximum number of PoC sessions in step 210. If User B has already reached the maximum limit of the simultaneous PoC sessions, PoC client B replies to the INVITE message with a “REJECT” message in steps 212 to 220. PoC client B keeps on replying with the busy state notification till User B has released at least one of the existing PoC sessions.
As described above, when User A invites User B to join a PoC session in the PoC simultaneous session scenario at the PoC client, the PF routes the INVITE message to User B. Then if the requesting PF client recognizes that User B is “too busy for the simultaneous session”, the PF responds back to User A automatically. Alternatively, the PF responds to User A that User B is busy, directly without routing the INVITE message to User B.